
\chapter{QUADRO TEÓRICO}
%http://stackoverflow.com/questions/2166557/how-to-hide-the-page-number-in-latex-on-first-page-of-a-chapter
\thispagestyle{empty}

\par Neste capítulo serão apresentadas as tecnologias que serão utilizadas no
desenvolvimento deste trabalho.



\section{Grafos}

\par Segundo \citeonline{netto2006grafos}, a teoria dos grafos teve início em
meados do século XVIII, quando Leonhard Euler resolveu um desafio difundido
entre moradores da cidade de Königsberg, hoje conhecida como Kaliningrad na
Rússia. A cidade era cortada por pelo rio Pregel e havia sete pontes que
conectavam duas ilhas com a cidade, com ilustrado na Figura~\ref{fig:ponte_k}.
O desafio proposto pelos moradores era determinar se era possível atravessar
cada ponte exatamente uma vez durante um passeio, sem passar duas vezes pela
mesma ponte. Segundo \citeonline{digrafos}, Euler apresentou um artigo chamado
\textit{Solutio problematis ad geometriam situs pertinentis} à Academia de Ciências de St.
Petersburgo no qual prova não ser 
possível fazer o percurso proposto no desafio, nascendo assim a teoria dos
grafos.

\begin{figure}[h!]
  \centerline{\includegraphics[scale=.55]{./imagens/ponte_k.png}}
  \caption[As sete pontes de Königsberg.]{As sete pontes de Königsberg.
  \textbf{Fonte:}
  \cite{pontes_teoria}}
\label{fig:ponte_k}
\end{figure}

\par A definição de grafo, segundo \citeonline{pontes_teoria},

\begin{citacao}
	é um par ordenado de conjuntos disjuntos $(V, A)$, onde
	$V$ é um conjunto arbitrário que se designa por conjunto dos vértices e
	$A$ é um subconjunto de pares não ordenados de elementos (distintos) de
	$V$ que se designa por conjunto de arestas.
\end{citacao}

\par Um grafo pode ser utilizado para representar vários tipos de dados, como
estruturas rodoviárias, mapas aéreos, rede de amigos, entre outros. Um modelo de
grafos é ilustrado na Figura~\ref{fig:grafo_1}, onde é destacado dois vértices e uma
aresta.

 \begin{figure}[h!]
  \centerline{\includegraphics[scale=1.2]{./imagens/exemplo_grafo.png}}
  \caption[Exemplo de grafo.]{Exemplo de grafo.
  \textbf{Fonte: }
  Elaborado pelo autores}
\label{fig:grafo_1}
\end{figure}

\par Dois conceitos importantes da teoria dos grafos são: ordem e dimensão, que
segundo \citeonline{pontes_teoria}, dado um grafo $G=(V,A)$, ``A ordem de
$G$, denotada por $|V|$, é o número de vértices de $G$ e a
dimensão de $G$, denotada por $|A|$, é o número de arestas de
$G$''. Um grafo pode ter zero ou mais arestas que interligam os vértices. Um
grafo completo é aquele que todos os seus vértices estão conectados entre si.

\par Uma característica importante de um grafo é a forma simples com que ele
representa dados que contenham relacionamentos. Essa forma de armazenamento faz
com que sejam formados caminhos que podem revelar informações importantes para
determinados problemas, como o do caixeiro viajante. Segundo
\citeonline{digrafos} ``Um caminho (\textit{path}) em um grafo é uma sequência
de vértices dotada da seguinte propriedade: se $z$ e $w$ são
vértices consecutivos na sequência então $z-w$ é uma aresta''. Todo
caminho possui um início e um fim, sendo eles o primeiro e o último
vértice respectivamente. Segundo \citeonline{digrafos} ``O comprimento
(\textit{length}) de um caminho é o número de vértices da sequência menos um'',
ou seja, é a soma de todas as arestas do caminho.

\par Para se percorrer um caminho  são utilizados algoritmos de busca que,
segundo \citeonline{digrafos} ``é um algoritmo que
visita, sistematicamente, todos os vértices e todos os arcos de um grafo''.
Através deste método, pode-se resolver vários problemas
representados por um grafo, como encontrar o caminho mais curto. Basicamente,
existem duas técnicas de busca:
\begin{itemize}
  \item \textbf{Busca em profundidade (\textit{DFS})}: segundo \citeonline{digrafos}, é um
algoritmo que se concentra em buscar, sempre que possível, o vértice mais fundo
no grafo explorando a partir de um vértice $V$, recentemente descoberto,
que ainda possui arestas não exploradas. Ele utiliza uma pilha para armazenar os
vértices visitados para que depois de alcançar a profundidade máxima possa voltar aos vértices anteriores.
  \item \textbf{Busca em largura (\textit{BFS})}: segundo \citeonline{digrafos}, 
é um algoritmo que, a partir de um vértice $V$, explora todos os
vértices que estão ligados a ele. Depois de visitar todos os vértices daquele
nível,  ele expande a pesquisa para os vértices visitados e assim sucessivamente até percorrer todos os
vértices do grafo. Para garantir que nenhum vértice seja visitado duas vezes, o algoritmo
utiliza uma fila que utiliza o método FIFO,  que garante a ordem de chegada dos
vértices.
\end{itemize}

\section{Modelo relacional e SQL}

\par A décadas, os SGBDs são utilizados como uma
importante ferramenta para armazenamento de dados.
Segundo \citeonline{modelo_relacional}, com o passar do tempo, estes sistemas
começaram a usar diferentes modelos de dados para representar as informações
contidas no banco. Os modelos mais utilizados, segundo
\citeonline{modelo_relacional} são: modelo hierárquico, modelo em redes,
o modelo orientado a objetos e o mais importante e utilizado, o modelo
relacional. Segundo \citeonline{desql}, o modelo de dados relacional foi
introduzido por Codd em 1970 e teve como base um modelo formal baseado nos conceitos de 
conjuntos representando o banco de dados como uma coleção de relações. O sistema
R foi o primeiro SGBDR implementado.

Segundo \citeonline{desql}, em conjunto com o Sistema R os pesquisadores da IBM
desenvolveram o SEQUEL, uma linguagem de acesso para sistemas de gerenciamento
de banco de dados relacionais. Com o desenvolvimento e a implementação de novos
SGBDR, foi necessário desenvolver uma liguagem de acesso padrão, nascia assim o
SQL (Structured Query Language), \cite{desql}. A linguagem SQL pode ser
subdividida em duas sub-linguagens a DML (\textit{Data Manipulation Language}) e a DDL
(\textit{Data Definition Language}). Segundo \citeonline[p. 16]{desql} A DML
``trata dos comandos ligados à manipulação de dados, definindo os comandos para a seleção,
inclusão e exclusão de dados de tabelas'' e segundo \citeonline[p. 16]{desql} a
DDL ``reúne os comandos para a criação e manutenção de estruturas e objetos do banco de
dados, tais como tabelas, visões e índices''.

\section{NoSQL}

\par Por muitos anos, os bancos relacionais se apresentaram como a única opção
em armazenamento de dados. Esta ``cultura relacional'' que perdura
devido a décadas de utilização, principalmente em aplicações corporativas, tem
sido ameaçada por um novo conceito de banco de dados.

\par Depois de um longo período no qual o banco relacional predominou
isoladamente, os desafios propostos por aplicações distribuídas, têm feito com
que novos tipos de dados surjam e tratá-los tem se tornado cada vez mais
complexo e sua manutenção mais cara. Para enfrentar este novo cenário,
proporcionado pela popularização da \textit{internet}, grandes empresas
investiram em bancos de dados que têm como principal objetivo atender aos requisitos de suas aplicações.

\par Tais bancos são conhecidos como bancos NoSQL. Segundo
\citeonline{sadalage2012nosql}, não existe uma definição genericamente aceita
para o termo. O que existe é uma série de fatores que fazem com que diversas
implementações de técnicas de armazenamento sejam classificados como tal.
 \citeonline{sadalage2012nosql} sugerem ainda, em seu livro, alguns fatores que
 caracterizam um banco de dados NoSQL:
 \begin{itemize}
   \item não utiliza o modelo relacional;
   \item tem uma boa execução em \textit{clusters};
   \item seu código é aberto (\textit{open source});
   \item não possui esquema.
 \end{itemize}
  \par Segundo \citeonline{sadalage2012nosql}, ``é melhor pensar em NoSQL como um movimento
  em vez de uma tecnologia''. Isso faz com que o NoSQL se torne um
  ecossistema de soluções de armazenamento de dados que oferece soluções para
  aplicações do mundo moderno, em que há uma alta complexidade e um grande volume
  de dados. Este segmento não pode ser visto como substituto do modelo
  relacional que oferece estabilidade e uma variedade de recursos que atendem a
  diversos requisitos de aplicações. O movimento se apresenta como uma solução
  que visa atender a problemas específicos em aplicações modernas. Segundo
  \citeonline{sadalage2012nosql},
  \begin{citacao}
        A diferença significativa é que agora vemos os bancos de dados
        relacionais como uma opção para o armazenamento de dados. Esse ponto de vista é, muitas vezes, chamado de persistência poliglota -- utilizar diferentes armazenamentos de dados em diferentes circunstâncias. Em vez de escolher o
  	  	banco de dados relacional mais utilizado por todos, precisamos entender a
  	  	natureza dos dados que estamos armazenando e como queremos manipulá-los. O
  	  	resultado é que a maioria das organizações terá uma mistura de tecnologias
  	  	de armazenamneto de dados para diferentes circustâncias.
  \end{citacao}
  \par Hoje já é possível encontrar uma grande variedade de bancos NoSQL. No
  \textit{site} oficial do movimento \footnote{\textit{Site} oficial:
  \url{http://nosql-database.org/}}, pode ser encontrada uma lista de soluções que são
  classificadas de acordo com a forma de armazenamento. Na
  Tabela~\ref{tab:nosql_databases} são apresentados os tipos de bancos
  existentes e os principais produtos disponíveis.


\begin{table} [h]
  \centering
  \begin{tabular}{|p{3in}|p{3in}|}
    \hline 
    %\multicolumn{1}{|c|}{\textbf{Tipos}} &
    % \multicolumn{1}{c|}{\textbf{Produtos}} \\
	Wide Column Store / Column Familie
	&Hadoop / Hbase, Cassandra, Hypertable
	\\
    \hline 
	Documents Store
	&MongoDB, Elasticsearch, CouchDB
	\\
    \hline
	Key Value / Tuple Store
	&DynamoDB, Redis, Azure Table Storage
	\\

    \hline
	Graph Databases
	&Neo4j, Infinite Graph, InfoGrid
	\\

    \hline
	Multimodel Databases
	&Datomic, ArangoDB, OrientDB
	\\

    \hline
	Object Databases
	&Versant, db4o,Objectivity
	\\
	\hline
	Grid and Cloud Database Solutions
	&GigaSpaces, GemFire, Infinispan
	\\
	\hline
	XML Databases
	&Axist, Sedna, BaseX
	\\
	\hline
	Multidimensional Databases
	&Globals, Intersystems Cache, GT.M
	\\
	\hline
	Multivalue Databases
	&U2, OpenInsight, Reality
	\\
	\hline
	Event Sourcing
	&Event Store
	\\
	\hline
	Other
	&IBM Lotus/Domino, eXtremeDB, RDM
	\\
    \hline 
  \end{tabular}
  \caption[Bancos NoSQL.]{Bancos NoSQL. \textbf{Fonte:} \cite{site_nosql}}
  \label{tab:nosql_databases}
\end{table}
\par A seguir serão apresentados os principais bancos NoSQL e suas
características.

% Bando de dados orientado a documentos

\subsection{\textit{Document Stores}}

\par Os \textit{Document Stores} formam uma classe de sistemas de
armazenamento que salvam e recuperam objetos inteiros hierarquicamente em um
disco sem o uso de tabelas relacionais.
De acordo com \citeonline[p.~186]{robinson2013graph}, \textit{Document Stores}
armazenam e recuperam documentos, como um armário de arquivamento eletrônico. De forma mais simples, os documentos podem ser
armazenados e recuperados através de um ID. Mas, no caso geral, os
\textit{Document Stores} dependem de índices para facilitar o acesso aos
documentos com base em seus atributos. Em geral os
índices são usados para recuperar conjuntos de documentos relacionados em um
repositório para que os mesmos possam ser utilizados por uma aplicação
\cite{robinson2013graph}.
\par Os \textit{Document Stores} geralmente têm mecanismos de consultas muito
poderosos e recursos de indexação que tornam mais fácil e rápido executar várias
consultas diferentes. A força da linguagem de consulta do modelo é um importante
diferencial deste banco de dados.

\subsection{\textit{Key Value Store}}
\par O \textit{Key Value} é um dos bancos NoSQL mais simples, em que a ideia
principal é armazenar objetos utilizando uma chave. Segundo
\citeonline[p. 6]{loscio_nosql}  ``o banco de dados é composto por um conjunto
de chaves as quais estão associadas um único valor que pode ser uma
\textit{string} ou um binário''. Originalmente, o objetivo de um \textit{Key
Value Store} era de rodar no \textit{back-end} de um servidor \textit{web}, cuja arquitetura é orientada a objetos. 
A abordagem é muito simples, ele armazena cada objeto de acordo com uma chave
única que geralmente é serializada, oferecendo suporte à busca, comparação e
classificação dos valores armazenados na base de dados e, em sua maioria,
apresentam operações bem simples como \textit{get()} e \textit{set()} que tem
a função de retornar e armazenar valores, respectivamente \cite{loscio_nosql}.
Isso resulta em uma arquitetura livre, em que qualquer tipo de valor
pode ser armazenado. 

\subsection{Graph Databases}

\par Segundo \citeonline{neo4j_doc}, ``Um banco de dados orientado a grafos,
armazena os dados em um grafo, que é a mais genérica estrutura de dados, capaz
de respresentar elegantemente qualquer tipo de dado de uma forma muito
acessível''. Em contraste com os modelo NoSQL já apresentados, que são
basicamente orientados à chave, o \textit{Graph Database} é um tipo de banco
especializado na manipulação de dados fortemente ligados, ou seja, ele pode ser
considerado um banco orientado a relacionamentos \cite{robinson2013graph}.
Ele é composto basicamente por vértices e arestas como é ilustrado na Figura ~\ref{fig:grafo_2}.

\begin{figure}[h!]
  \centerline{\includegraphics[scale=.3]{./imagens/small_graph.png}}
  \caption[Exemplo de dados em um \textit{Graph Database}.]{Exemplo de dados em
  um \textit{Graph Database}.
  \textbf{Fonte:}
  \cite{robinson2013graph}}
\label{fig:grafo_2}
\end{figure}

\par Em seu trabalho \citeonline{robinson2013graph}, citam que os
relacionamentos são muito importantes no modelo de grafos e 
diferentemente de outros bancos, onde é praticamente obrigatório inserir 
as conexões entre as entidades utilizando propriedades como chaves estrangeiras,
os relacionamentos são essenciais para a construção do modelo.

\par Ao construir uma abstração simples de vértices e arestas, o
\textit{Graph Database} permite construir sofisticados modelos de mapa que 
atendem ao problema proposto neste trabalho de forma simples e ao mesmo tempo mais expressivos 
que os produzidos por bancos de dados relacionais e outros bancos NoSQL.

\par Para que os dados possam ser explorados neste modelo de banco, é utilizado
um tipo de motor que executa os algoritmos de busca em largura e em
profundidade em um grafo. Segundo \citeonline{robinson2013graph}, um 
\textit{Graph Compute Engine} é uma tecnologia que permite que os algoritmos 
computacionais para grafos sejam executados em grandes volumes de dados. 
Ele é projetado para realizar consultas que em um banco relacional seria
necessário uma série de \textit{join's}, o que aumentaria tanto o tempo gasto pela consulta quanto a complexidade do
código SQL devido à quantidade de tabelas que devem ser interligadas.

\par A motivação para se utilizar um \textit{Graph Database} pode estar no fato
de modelar quase todas as formas de dados existentes através de um grafo, mas
isso pode não servir como argumento para se substituir uma plataforma bem
sucedida como o modelo relacional.
Em seu trabalho \citeonline[p. 8]{robinson2013graph} citam que ``a motivação existe 
sob a forma de um conjunto de casos de uso e padrões de dados cujo desempenho 
melhora por uma ou mais ordens de grandeza quando implementados em um modelo 
de grafo''. Através deste benefício de desempenho ele pode oferecer uma resposta
extremamente rápida, conforme a necessidade da aplicação.

\section{Neo4j}
\par O Neo4j é um banco NoSQL \textit{open source}, do tipo \textit{Graph
Database}, que foi completamente escrito em Java pela empresa Neo Technology.
Como o nome sugere, ele armazena os dados em uma estrutura de vértices e
arestas e é focado nos relacionamentos, deste modo é possível armazenar dados
com valores altamente variáveis de uma forma natural e relativamente fácil
\cite{neo4j_site}.
O banco Neo4j é pequeno o suficiente para ser incorporado em quase todas as
aplicações e pode armazenar milhões de vértices e arestas e pode
lidar com quantidades crescentes de dados \cite{neo4j_site}. 


\par Segundo \citeonline{robinson2013graph}, a solução Neo4j armazena um conjunto de
dados por meio de uma estrutura de grafo responsável por compor uma rede de
informações rica em conectividade e mais próxima da realidade. Indicada para
cenários com alta conectividade de dados, o Neo4j facilita a criação de modelos
de dados complexos, assim como a consulta e manipulação dos dados,
através de um ambiente transacional ACID (\textit{Atomicity, Consistency,
Isolation, Durability}). O comportamento ACID proporciona um alicerce de
confiabilidade dos dados, onde o Neo4j impõe que todas as operações que modificam
dados ocorram dentro de uma transação, garantindo dados consistentes. As
principais caraterísticas do Neo4j podem ser observadas na Tabela
~\ref{tab:neo4j_caracteristicas}.
\begin{table} [h]
  \centering
  \begin{tabular}{|p{1.65in}|p{4.3in}|}
    \hline 
    Intuitivo&Usa um modelo de grafo para representação dos dados
    \\
    \hline
    Confiável&Utiliza transações ACID
    \\
    \hline
    Durável e rápido&Usa mecanismo de armazenamento nativo personalizado
    \\
    \hline
    Massivamente escalável&Até vários bilhões de vértices, arestas e
    propriedades
    \\
    \hline
    Altamente disponível&Distribuíveis em várias máquinas
    \\
    \hline
    Expressivo&Com uma poderosa linguagem de consulta
    \\
    \hline
    Rápido&Com uma estrutura de travessia poderosa para consultas de alta
    velocidade no grafo
    \\
    \hline
    Embutido&Com alguns pequenos \textit{jars}
    \\
    \hline
    Simples&Acessível através de uma interface REST conveniente ou uma API (\textit{Application Programming Interface}) Java
    orientada a objeto
    \\
    \hline
    
    \end{tabular}
  \caption[Principais características do Neo4j.]{Principais características do Neo4j. \textbf{Fonte:} \cite{neo4j_site}}
    \label{tab:neo4j_caracteristicas}
    \end{table}
    

 \par As unidades fundamentais que formam um grafo são os \textit{nodes}
 (vértices) e os \textit{relationships} (arestas) e no Neo4j, ambos podem conter
 propriedades. Os vértices, segundo \citeonline{neo4j_doc}, muitas vezes são
 utilizados para representar entidades, 
 mas dependendo do tipo de domínio, eles também podem ser
 utilizados para outras finalidades. Já as arestas também são fundamentais em um
 \textit{Graph Database} e, segundo \citeonline{neo4j_doc}, elas permitem que os
 dados sejam localizados e, assim como os vértices, podem possuir propriedades. Uma aresta tem como finalidade
conectar dois vértices que são chamados de \textit{start node} e
\textit{end node} e definem a direção da aresta.
 Como é ilustrado na Figura~\ref{fig:node_and_relationship}, um vértice pode ter propriedades e
 arestas. Já uma aresta, obrigatoriamente possui um vértice início e um vértice 
 fim além de possuir um \textit{RelationshipType}, que segundo
 \citeonline{neo4j_doc}, basicamente define um rótulo para uma aresta, não pode
 receber o valor \textit{null} e tem como principal objetivo facilitar as travessias no grafo.
 
\begin{figure}[h!]
  \centerline{\includegraphics[scale=.4]{./imagens/node_and_relationships.png}}
  \caption[\textit{Node} e \textit{Relationship} no Neo4j]{\textit{Node} e
  \textit{Relationship} no Neo4j.
  \textbf{Fonte: }Adaptado de:
  \cite{neo4j_doc}}
\label{fig:node_and_relationship}
\end{figure}
 
\par As arestas podem ser percorridas em ambos os sentidos, isto
significa que não há necessidade de adicionar arestas duplicadas, 
em sentidos opostos. Embora as arestas sempre tenham uma direção, 
é possível ignorar o sentido caso não seja útil para a aplicação e ainda é
possível que um vértice tenha uma aresta com ele mesmo.
Tanto os vértices quanto as arestas no Neo4j podem ter propriedades.
Segundo \citeonline{neo4j_doc}, propriedades são pares chave-valor, em que a chave
é necessariamente uma \textit{String}. Como ilustrado na
Figura~\ref{fig:properties}, os valores relacionados a chave podem ser do tipo
primitivo\footnote{Um dado do tipo primitivo corresponde a dados mais simples ou escalares. São exemplos de dados primitivos: \textit{boolean,
byte, int, char}, entre outros. \textbf{Fonte: }
\url{http://www.dm.ufscar.br/~waldeck/curso/java/part22.html}} ou um \textit{array} de
tipos primitivos

\begin{figure}[h!]
  \centerline{\includegraphics[scale=.6]{./imagens/properties_neo4j.png}}
  \caption[\textit{Properties} no Neo4j]{\textit{Properties} no Neo4j.
  \textbf{Fonte: }Adaptado de:
  \cite{neo4j_doc}}
\label{fig:properties}
\end{figure}

\par Para realizar operações de consulta em um grafo é preciso que um caminho
seja percorrido, composto por um conjunto de relaciomentos,
geralmente obtidos como resultado de uma consulta. A Figura~\ref{fig:path}
ilustra como é composto um caminho no banco, visto que o caminho mais curto tem
comprimento zero e possui somente um vértice sem arestas.
\newpage
\begin{figure}[h!]
  \centerline{\includegraphics[scale=.6]{./imagens/path_neo4j.png}}
  \caption[\textit{Path} no Neo4j]{\textit{Path} no Neo4j.
  \textbf{Fonte: }Adaptado de:
  \cite{neo4j_doc}}
\label{fig:path}
\end{figure}

\par Os caminhos são muito utilizados para descrever uma travessia no banco,
este recurso pode ser considerado como um diferencial do banco e será
apresentado na próxima subseção.
\subsection{API \textit{Traversal}}
\par Outra importante ferramenta do Neo4j é o \textit{Traversal}.
Segundo \citeonline{neo4j_doc}, atravessar um grafo significa visitar seus vértices
seguindo as relações de acordo com regras pré-estabelecidas. A API
\textit{Traversal} permite que as regras de travessia do grafo sejam especifadas 
atarvés de um código Java. Segundo \citeonline{neo4j_doc}, a API possui métodos
que podem acrescentar ou modificar as regras de travessia:

\begin{itemize}
  \item \textit{Expander}: define a próxima aresta que será atravessada,
  com base nos parâmetros de direção e tipo de relacionamento;
  \item \textit{Order}: define se a travessia será por profundidade ou por
  largura;
  \item \textit{Uniqueness}: define que os vértices serão visitados apenas uma vez;
  \item \textit{Evaluator}: decide o que será retornado além de decidir se a
  travessia irá parar ou continuar para além da posição atual;
  \item \textit{Starting node}: onde a travessia começa.
\end{itemize}

\subsubsection{\textit{Traversal Description}}
\par Segundo \citeonline{neo4j_doc}, a interface
\texttt{TraversalDescription} é o principal elemento usado para definir e
inicializar uma travessia. Ela é fornecida pela implementação da estrutura de
travessia para que o usuário possa especificar de que forma a
travessia será feita. O método \texttt{relationship(\ldots)} adiciona um tipo de
relacionamento para atravessar e caso este método não seja chamado, a travessia
percorrerá todos os relacionamentos \cite{neo4j_doc}.

\subsubsection{Evaluators}

\par Segundo \citeonline{neo4j_doc}, os \textit{Evaluators} (avaliadores) são
utilizados para decidir se a travessia deve continuar ou se um vértice deve ser incluído em um
resultado. Dado um caminho, ele pode executar uma das quatro ações para cada
vértice em uma travessia:

\begin{itemize}
  \item \texttt{Evaluation.INCLUDE\_AND\_CONTINUE}: incluir o vértice no
  resultado e continuar a travessia;
  \item \texttt{Evaluation.INCLUDE\_AND\_PRUNE}: incluir o vértice no
  resultado e interromper a travessia;
  \item \texttt{Evaluation.EXCLUDE\_AND\_CONTINUE}: excluir o vértice do
  resultado e continuar a travessia;
  \item \texttt{Evaluation.EXCLUDE\_AND\_PRUNE}: excluir o vértice do
  resultado e interromper a travessia.
\end{itemize}

 \par Pode-se adicionar um ou mais avaliadores e eles serão chamados em todas
 as posições da travessia, até mesmo no \textit{start node} \cite{neo4j_doc}.
 
\subsubsection{\textit{Traveser}}
\par É o objeto retornado pelo método \texttt{traverse()} de um objeto
\texttt{TraversalDescription} e, segundo \citeonline{neo4j_doc}, representa uma
passagem pelo grafo.

\subsubsection{\textit{Uniqueness}}
\par A \textit{Uniqueness} (singularidade) pode ser fornecida ao
\texttt{TraversalDescription} para dizer se a travessia pode revisitar um
vértice do grafo, podendo possuir os seguintes opções:

\begin{itemize}
  \item \texttt{NONE}: Pode visitar os vértices mais de uma vez;
  \item \texttt{NODE\_GLOBAL}: Pode visitar os vértices somente uma vez;
  %\item \texttt{RELATIONSHIP\_GLOBAL}: Pode visitar as arestas somente uma vez;
  \item \texttt{NODE\_PATH}: Para cada vértice retornado, existe um caminho
  único do vértice inicial até ele;
 % \item \texttt{RELATIONSHIP\_PATH}: Para cada vértice retornado (), existe um  caminho único do vértice inicial até ele; 
  \item \texttt{NODE\_RECENT}: Semelhante ao \texttt{NODE\_GLOBAL}, mas com
  limite para a quantidade de memória consumida para gravar os vértices já
  visitados;
  %\item \texttt{RELATIONSHIP\_RECENT}: Semelhante ao \texttt{NODE\_RECENT} mas com aresta em vez de vértices.
   
\end{itemize}

\par Para o conceito de ordem da travessia o Neo4j fornece dois
métodos: \texttt{dephtFirst()} e \texttt{breadthFirst()}, que
realizam uma travessia em profundidade e em largura respectivamente \cite{neo4j_doc}.

\subsubsection{\textit{Path}}
\par A interface \texttt{Path} faz parte da API Neo4j, que, em
uma travessia, é utilizada para duas finalidades: 1) retornar resultados na
forma de caminhos dos vértices visitados no grafo que foram marcados para serem
devolvidos; 2) avaliar um vértice de um grafo para determinar se a passagem
deve continuar ou não e se certos vértices deverão ser incluídos no resultado
\cite{neo4j_doc}.

\subsubsection{\textit{Expander}}

\par A interface \texttt{Expander} é utilizada para fornecer métodos
para definir quais tipos de arestas serão percorridas durante a travessia
\cite{neo4j_doc}.

\par Na versão 2.0.0 do Neo4j foi disponibilizado um novo recurso chamado de
\textit{Label}, que segundo \citeonline{neo4j_doc} é utilizado para agrupar os
vértices. Assim todos os vértices marcados com o mesmo rótulo 
pertencem ao mesmo grupo. Com essa funcionalidade, 
as consultas tendem a ficar mais simples. 
Um vértice pode ser rotulado com um ou mais rótulos ou pode não ter nenhum. O
\textit{label} também pode ser adicionado e retirado a qualquer momento, o
que permite, por exemplo, rotular usuários que estão \textit{online} ou
\textit{offline}.


\subsection{Neo4j embutido no projeto Java}

\par O Neo4j oferece várias possibilidades de integração com um programa Java. Uma das opções é o
Neo4j-\textit{Server} que pode ser instalado e depois acessado através de sua
API REST. Mas também é possível utilizar o Neo4j incorporado no código Java
utilizando diretamente o Neo4j \textit{Core}-API. Assim é possível obter uma
abordagem orientada a objetos trabalhando com \textit{nodes}, \textit{relationships},
\textit{paths} e utilizando implementações de algoritmos altamente
personalizáveis e de alta performance. 

\par Para o uso do Neo4j dentro do código Java é disponibilizada uma API que
contém classes e \textit{interfaces} que são responsáveis por todo processo de
criação e interação com o banco, mostrados na Tabela~\ref{tab:neo4j_recursos}.

\begin{table} [h]
  \centering
  \begin{tabular}{|p{1.8in}|p{4.1in}|}
    \hline 
    \multicolumn{1}{|c|}{\textbf{\textit{Interfaces}}} 
    &
    \multicolumn{1}{c|}{\textbf{Descrição}} 
    \\
    \hline
    \texttt{GraphDatabaseService}
    &
    O principal ponto de acesso a uma instância do Neo4j, fornece métodos para
    criar e recuperar vértices e \textit{shutdown} do Neo4j.
    \\
    \hline 
    \texttt{Node}
    &
    Um vértice que possui propriedades e arestas, é o principal elemento do
    banco Neo4j junto com o \texttt{Relatioship}.
    \\
    \hline
    \texttt{Relationship}
    &
    Uma aresta entre dois vértices.
    \\
    \hline
    \texttt{PropertyContainer}
    &
    Possui uma API comum para lidar com propriedades de vértices e arestas.
    \\
    \hline
    \texttt{Transaction}
    &
    Utilizada para manipular por linha de código uma transação. Todas as
    operações de modificação devem ser feitas dentro do escopo de uma transação.
    \\
    \hline
    \texttt{RelationshipType}
    &
    É usado para atravessar um grafo. Obrigatório em todos os relacionamentos e
    fundamental para a estrutura do \textit{Traveser}.
    \\
    \hline
    \texttt{Path}
    &
    Representa um caminho em um grafo.
    \\
    \hline
    \texttt{Index}
    &
    Associa com pares chave-valor com vértices ou arestas para facilitar uma
    consulta no banco.
    \\
    \hline
    \texttt{Traverser}
    &
    Provê acesso aos resultados de uma travessia.
    \\
    \hline
    \texttt{TraversalDescription}
    &
    Representa a descrição de uma travessia.
    \\
    \hline
    \multicolumn{1}{|c|}{\textbf{Classes}} 
    &
    \multicolumn{1}{c|}{\textbf{Descrição}} 
    \\
    \hline
    \texttt{Evaluators}
    &
    Possui métodos para avaliação de travessias
    \\
    \hline
    \texttt{GraphDatabaseFactory}
    &
    Possui metodos utilizados para criar uma instância do banco de dados Neo4j.
    \\
    \hline
    \multicolumn{1}{|c|}{\textbf{Enums}}
    &
    \multicolumn{1}{c|}{\textbf{Descrição}}
    \\
    \hline
    \texttt{Direction}
    &
    Define a direção de uma aresta.
    \\
    \hline
    
  \end{tabular}
  \caption[Principais recursos da API Neo4j]{Principais recursos da API Neo4j.\textbf{Fonte:} \cite{neo4j_api}}
  \label{tab:neo4j_recursos}
\end{table}

\par Esta API mostra os principais recursos da API Neo4j na versão 1.9.4. 
 O processo de instalação do Neo4j está documentado no Anexo B do projeto.
%\section{JBoss Seam}

%\par Visando agilizar o processo de desenvolvimento de \textit{software}, muitas
%empresas optam por utilizar \textit{frameworks~\footnote{Os frameworks facilitam o
%desenvolvimento de software, permitindo que os programadores se ocupem mais 
%com os requerimentos do software do que com os detalhes tediosos, de baixo nível
% do sistema.}} que são ferramentas que tem como objetivo agilizar o processo de
% implementação de uma aplicação. O JBoss Seam é um dos \textit{frameworks} mais
% conhecidos do mercado e foi escolhido para ser utilizado neste trabalho por
% possuir uma grande quantidade de material disponível.
 
% \par Um \textit{framework} tem como principal vantagem facilitar o processo de
% desenvolvimento, simplificando os processos de rotina, fornecendo utilitários
% nativos que dispensam algumas configurações manuais. O Seam basicamente extende
% e simplifica a utilização da plataforma JEE.
 
% \par O ambiente JEE é formado pelo Java Standard Edition(Java SE) junto com
% o conjunto de APIs dentre eles JDBC para acesso ao banco, JAXP para
% processamento de XML, que são a base para todos recursos da camada enterprise 
% do JEE(JSF/JSP/servlets) que são utilizados no desenvolvimento web. A
% figura ~\ref{fig:jboss} emplifica o modelo padrão JEE.
 
%\begin{figure}[h!]
%  \centerline{\includegraphics[scale=0.8]{./imagens/jboss-new.png}}
% \caption[\textit{Framework} padrão JEE.]{\textit{Framework} padrão JEE.
%  \textbf{Fonte:}
%  \cite{farley2007practical}.}
%\label{fig:jboss}
%\end{figure}
 
 
%\begin{figure}[h!]
 % \centerline{\includegraphics[scale=0.7]{./imagens/jboss2-new.png}}
 % \caption{\textit{JBoss Seam}. \textbf{Fonte:} \cite{farley2007practical}}
%\label{fig:jboss2}
%\end{figure}
 
 %\par Um dos pontos positivos fornecidos pelo Seam esta diretamente ligado ao
 %seu modelo de arquitetura de componentes que demonstra ser simplificada.
 %Segundo \citeonline[p. 3]{farley2007practical}, " Um beneficio fundamental 
 %deste modelo de componentes do Seam é a  forma em que
 %os EJBs são integrados as paginas JSF.''
 \section{Apache Tomcat}
 \par Segundo \citeonline[p. 1]{vukotic2011apache}, o ``servidor Apache Tomcat
 é um \textit{container web}, de código aberto  e baseado em Java que foi criado
 para executar aplicações \textit{web} que utilizem tecnologias 
 \textit{Servlet} e JSP''. Segundo \citeonline{site_tomcat_jakarta}, sua
 criação foi baseada no Apache-Jakarta, um sub-projeto da empresa que teve
 sua fundação em 1999 e abrigava um conjunto diversificado de soluções para
 Java.
 Em 2005 o sub-projeto Jakarta foi subdividido em projetos que passaram a ser
 considerados pela empresa como sendo de um nível superior, dentre eles
 o Apache Tomcat que, devido à sua popularidade, tornou-se um projeto separado,
 sendo mantido por um grupo de voluntários da comunidade Java.
 \par Segundo \citeonline{vukotic2011apache}, a arquitetura do Tomcat consiste
 em grupos de componentes que possuem uma hierarquia bem
 definida. Os principais componentes da hierarquia se encontram na
 Catalina \textit{Servlet Engine}, que é o atual Java \textit{Servlet}
 \textit{container} e além disso ele implementa a \textit{Servlet} API 3.0, sendo esta a última especificação do \textit{servlet}
 \cite{vukotic2011apache}. A Figura~\ref{fig:arquitetura_tomcat} ilustra a relação de hierarquia
 entre os diferentes componentes do Tomcat.


\begin{figure}[h!]
 \begin{lstlisting}[style=custom_XML]
															Server
															  Service
															    Connector
															    Engine
															      Host
															        Context
\end{lstlisting}
 

% \centerline{\includegraphics[scale=0.8]{./imagens/arquitetura_reconhecimento_tomcat.png}}
\caption[Principais componentes da arquitetura do Tomcat.]{Principais componentes da arquitetura do Tomcat.
 \textbf{Fonte:}
 \cite{vukotic2011apache}.}
\label{fig:arquitetura_tomcat}
\end{figure}

\par Esta estrutura pode ser dividida em um conjunto de componentes \cite{vukotic2011apache}:

\begin{itemize}
   \item \textit{Server}: representa todo o servidor Catalina \textit{Servlet
   Engine} e é usado como um elemento de nível mais alto para uma simples
   instância do Tomcat. O elemento \texttt{Server} pode ter um ou mais
   elementos \texttt{Service}.

   \item \textit{Service}: contém uma coleção de um ou mais
   \texttt{Connector} que compartilham uma única \texttt{Engine}.

   \item \textit{Connector}: define as classes que fazem
   o atual gerenciamento das requisições e respostas de uma
   chamada de uma aplicação.

   \item \textit{Engine}: gerencia todas as
   requisições recebidas por todos os \texttt{Connector} definidos.

   \item \textit{Host}: define os \textit{hosts} virtuais que
   estão contidos em cada instância da \texttt{Engine} Catalina. Cada
   \texttt{Host} pode ser um pai para uma ou mais aplicações \textit{web},
   sendo representada por um componente \texttt{Context}.

   \item \textit{Context}: é o \textit{container}
   mais utilizado em uma instância do Tomcat. Cada elemento \texttt{Context}
   representa uma aplicação \textit{web} individual que está sendo executada
   dentro de um \texttt{Host} definido. Não existe limite para o número de contextos que
   podem ser definidos dentro de um \texttt{Host}.
 \end{itemize}

\par Por padrão, cada um desses componentes é configurado usando o arquivo \texttt{server.xml}.
  
\par A Figura~\ref{fig:arquitetura_tomcat_diagrama} mostra o relacionamento dos
componentes principais da arquitetura Tomcat que correspondem com a hierarquia 
da Figura~\ref{fig:arquitetura_tomcat}.
 
\begin{figure}[h!]
 \centerline{\includegraphics[scale=0.7]{./imagens/arquitetura_tomcat.png}}
\caption[Diagrama da arquitetura do Tomcat.]{Diagrama da arquitetura do Tomcat.
 \textbf{Fonte:}
 \cite{vukotic2011apache}.}
\label{fig:arquitetura_tomcat_diagrama}
\end{figure}
 
\par Como um recipiente \textit{Servlet}, o Tomcat, segundo
\citeonline{chopra2011professional}, é uma peça chave de um conjunto mais amplo
de normas coletivamente denominados de plataforma Java \textit{Enterprise
Edition} (JEE). \citeonline{chopra2011professional} também definem o padrão JEE
como sendo um conjunto de APIs, baseadas em Java, que são adequadas para a
criação de aplicações \textit{web} tendo foco em empresas de
diferentes portes, para tirar vantagem desta plataforma.
\citeonline{chopra2011professional} alegam que muitas tecnologias JEE são especialmente projetadas para resolver os problemas associados com a
criação de \textit{software} de grande porte. O JEE é construído sobre o
\textit{Java Standard Edition} (Java SE). Java SE e JEE são referidos como
plataformas, porque eles fornecem a funcionalidade central que atua como uma
 base sobre a qual as aplicações podem ser construídas.

\par Uma observação interessante, segundo \citeonline{chopra2011professional}, é
que o Tomcat, na maioria das vezes, é referenciado como sendo somente uma
implementação de \textit{servlets} e JSP, no entanto o Tomcat fornece
implementações como JNDI e JMX APIs. Mesmo assim ele não é um
servidor de aplicações JEE, pois não oferece suporte para a maioria
das APIs definidas pelo JEE.


 \section{\textit{Java Server Faces}}
 
 \par O \textit{Java Server Faces} (JSF) pode ser descrito como uma
 especificação para um \textit{framework} de componentes, que tem como foco o desenvolvimento
 \textit{web}.
 Segundo \citeonline{alexandreAltair2010JavaWeb} essa especificação foi
 construída para ser utilizada como um complemento no desenvolvimento JEE,
 definida pelo \textit{Java Community Process} (JCP), uma entidade que tem como principal meta criar especificações que resultem na evolução da
 linguagem Java, de forma que possam ser utilizadas no mercado de
 trabalho. 
 
 \par Mesmo que a especificação JSF tenha sua ideia
 inicial através da \textit{Java Community Process}, segundo \citeonline{alexandreAltair2010JavaWeb}, o apoio e aprovação de
 grandes empresas como IBM, Macromedia, Novell, Oracle, Siemens e a criadora
 Sun foi essencial para que essa especificação se tornasse um padrão de
 mercado. Com o apoio destas empresas, a especificação ganhou força e atenção
 de várias outras empresas do mercado, que se sentiram seguras para investir
 nesta especificação além das contribuições por meio de pesquisas e
 desenvolvimento de componentes, que tornaram sua utilização prática nos dias
 de hoje.
 
 \par Mesmo sendo utilizada por inúmeras empresas, esta especificação não é
 vista como um produto, pela JCP, que tem como ideia de um produto a
 implementação de um \textit{software} utilizando esta especificação. As
 implementações mais conhecidas JSF são:
 
 \begin{itemize}
   \item Mojarra: uma implementação da empresa Sun, criadora da linguagem Java;
   \item MyFaces: uma implementação da empresa Apache.
 \end{itemize}

 \par  Segundo \citeonline{alexandreAltair2010JavaWeb}, essas especificações são
 responsáveis por permitir a utilização dos componentes pertencentes ao HTML
 como: tabelas, formulários e o restante de \textit{tags} derivadas do HTML,
 não sendo apenas uma especificação focada na interface, mas também possibilita
 construir com facilidade a relação de interface com a inteligência utilizada
 pelas classes Java. Algumas das bibliotecas citadas por
 \citeonline{alexandreAltair2010JavaWeb} que tiveram sua implementação utilizando a especificação JSF, são:
 \begin{itemize}
   \item Tomahawk (Apache MyFaces); 
   \item Trinidad (Apache MyFaces); 
   \item Tobago (Apache MyFaces);  
   \item RichFaces (JBoss); 
   \item ICEFaces (ICESoft);
   \item PrimeFaces (Mojarra).
 \end{itemize}
 \par O funcionamento desta especificação difere do HTML puro, sendo
 implementada fornecendo padrões para que o desenvolvimento se tornasse prático
 e eficaz utilizando arquivos XML, XHTML e bibliotecas JSTL. Na elaboração de
 um projeto utilizando o JSF existem procedimentos necessários para sua
 utilização de forma associativa entre classes Java e interface JSF, alguns dos
 procedimentos citados por \citeonline{alexandreAltair2010JavaWeb} são comentados a seguir:
 \begin{itemize}
   \item criação das classes \textit{Backing Bean} (classes \textit{Beans});
   \item mapeamento das classes \textit{Bean}. 
 \end{itemize}
 \par Esses pontos são abordados, descrevendo como é a organização de um projeto
 utilizando esta especificação, com a finalidade inicial de criar classes Java capazes de interagir 
  com a interface JSF, tendo como procedimento a criação das classes \textit{Bean} e o 
  mapeamento realizado nessas classes.
 \par As classes \textit{Bean} são classes Java normais condicionadas a suportar 
 todo funcionamento do JSF. Desta forma permitindo que toda lógica se encontre
 separada da interface do usuário. As classes \textit{Bean} são responsáveis por apresentar todo conteúdo 
 existente na interface do usuário através de vínculos configurados antecipadamente, desta 
 forma cada elemento da interface que possua um evento estará associado a um método existente 
 na classe Bean. Para que essa associação aconteça, são utilizadas configurações de mapeamento e 
 \textit{Expression Language} que, segundo \citeonline[p. 37]{harwani2009Jsf}
 ``é utilizada para simplificar o acesso aos dados do JavaBean''. Sua estrutura é
 formada por uma cerquilha e duas chaves que agrupam o apelido da classe seguido da propriedade na qual deseja 
 se referir. A Figura~\ref{fig:jsf2} ilustra um componente JSF onde a
 \textit{Expression Language} está sendo utilizada dentro da propriedade
 \textit{value}, em que \textit{UserBean} é o nome da classe apelidada e
 \textit{name}, uma propriedade desta classe.


 
 \begin{figure}[h!]
  \begin{lstlisting}[style=custom_XML]
<?xml version="1.0" encoding="UTF-8"
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html">
	<h:head>
		<title>Welcome</title>
	</h:head>
	<h:body>
		<h:form>
			<h3>Please enter your name and password.</h3>
			<table>
				<tr>
					<td>Name:</td>
					<td><h:inputText value="#{user.name}"/></td>
				</tr>
				<tr>
					<td>Password:</td>
					<td><h:inputSecret value="#{user.password}"/></td>
				</tr>
			</table>
			<p><h:commandButton value="Login" action="welcome"/></p>
		</h:form>
	</h:body>
</html>
\end{lstlisting}

  \caption[Exemplo de código JSF.]{Exemplo de código JSF. \textbf{Fonte:} \cite{farley2007practical}}
\label{fig:jsf2}
\end{figure}

 \par Para que as \textit{interfaces} possam ter acesso às propriedades da
 classe \textit{Bean} é necessário que seja feito um mapeamento da classe, através 
 de duas maneiras: \textit{Annotations} e arquivo XML, chamado de
 \textit{faces-config.xml}, mapeamento este necessário para que haja uma
 definição de páginas para interação da aplicação, mas existem certas particularidades
 envolvendo a navegação, como o mapeamento condicional.
 
 \subsection{Ciclo de vida JSF}
 \par O mapeamento de uma classe \textit{Bean} e sua construção podem ser
 descritos como peças de um ciclo de vida que é pertencente ao contexto de um processo de um \textit{software},
 tendo um início de processo e findando em certo momento. Uma definição feita
 por \citeonline{alexandreAltair2010JavaWeb}, descreve que um ciclo de vida de
 um \textit{software} como sendo todas as atividades executadas durante sua
 existência e enfatiza que as relações entre as atividades provocam,
 inevitavelmente, mudanças nas aplicações. Os processos JSF não fogem à regra,
 pois seus ciclos obedecem a uma sequência de processos. A Figura~\ref{fig:ciclo_de_vida}
  exemplifica o ciclo de vida de uma requisição JSF
 exibindo a descrição das diferentes fases que constituem esse processo.
 \begin{figure}[ht!]
   \centerline{\includegraphics[scale=1.0]{./imagens/ciclo_de_vida_jsf.jpg}}
   \caption[Ciclo de vida JSF.]{Ciclo de vida JSF. \textbf{Fonte:}
   \cite{siteImagemIBM}}
   \label{fig:ciclo_de_vida}
  \end{figure}
  \par Segundo \citeonline[p. 101]{alexandreAltair2010JavaWeb}, cada fase do
  ciclo de vida do JSF existem as seguintes definições:
  \begin{itemize}
   \item \textbf{Restore View}: Carregam na memória todos os componentes formando uma árvore de objetos;
   \item \textbf{Apply Request Values}: Preenche a árvore de componentes com valores de uma requisição; 
   \item \textbf{Process Validation}: Percorre os componentes validando os
   valores registrados obedecendo às regras definidas pelo desenvolvedor;
   \item \textbf{Update Model Values}: Depois dos dados validados no
   componente, os dados são envia\-dos para a classe \textit{Bean};
   \item \textbf{Invoke Application}: Executa o evento desejado;
   \item \textbf{Render responsse}: Renderiza a página a ser exibida no navegador.
 \end{itemize}
 \par \citeonline[p. 101]{alexandreAltair2010JavaWeb} descreve cada processo vinculado ao ciclo de vida do 
 início, quando ocorre o armazenamento em memória, no percurso em que ocorrem
 validações até sua finalização quando é exibida a aplicação no navegador. Este
 processo é repetido a cada requisição realizando desta forma em um ciclo de vida.
 
 \section{Iconix}

 \par O Iconix, criada na década de 
 80 por Rosenberg e Scott(2005), permanece com seu foco em 
 análises e em uma implementação limpa, respeitando todos os requisitos do sistema.
 
 \par Dentre as análises propostas por essa metodologia, inicialmente é realizada a identifição dos usúarios 
 (chamados de atores) e qual o papel que determinado ator terá ao iteragir com o sistema. Suas atividades são 
 descritas como {casos de uso} que representam inicialmente relacionamentos com atividades do mundo real. 
 Essas atividades terão relações de objetos que descrevem o processo como um todo em determinada ação do 
 usuário, podendo, em determinado ponto, analisar a sequência de processos e seu
 ciclo de vida de forma detalhada.
 
 \par Uma das vantagens em utilizar esta metodologia é que sua base de
 especificações e a forma em que a modelagem do sistema é representada foi
 herdada da \textit{Unifield Modeling Language} (UML). O ICONIX possui seu foco nos requisitos, e utiliza desta técnica que 
  possibilita um desenvolvimento com mais clareza e agilidade ao longo do processo, garantindo,  mesmo que 
  ocorram modificações ao longo da implementação, a facilidade em efetuar as
  alterações nos requisitos.
 
 %\par Essa metodologia  não é a única existente no mercado. Outras metodologias como \textit{Extreme Programming} 
 %(XP) e \textit{Rational Unified Process} (RUP) têm sua eficiência e foco
 %reconhecidos. As principais diferenças entre as metodologias citadas se encontra na documentação e implementação. O RUP é considerado um processo 
 %pesado, pois ele exige uma documentação muito extensa. A outra metologia citada, o XP, tem seu foco em um 
 %desenvolvimento agil, baseado em requisitos, mas ele não proporciona uma documentação muito detalhada. 
 %Entretanto a metodologia ICONIX agrega o melhor das duas metodologias citadas de forma equilibrada e 
 %proporcionando um processo agil e bem documentado.
 
 \par Uma outra característica do ICONIX herdada da UML, é que ela possui “Rastreabilidade dos requisitos”. 
 Segundo \citeonline[p.3]{siteSayaoMonografia},  a  rastreabilidade  de  requisitos  provê  o  relacionamento  
 entre  os  requisitos  e  a 
arquitetura,  que  possibilita  a  compreensão  entre  os  relacionamentos  e  sua  implementação.

\par A rastreabilidade também é vista como a habilidade de acompanhar e detalhar o ciclo 
de  vida  de  um  requisito,  desta  forma,  a  utilização  do  ICONIX  fornece  a  seu  usuário  um 
controle maior dos processos, possibilitando verificar em todas as fases se os requisitos estão 
sendo atendidos. 

\par O ICONIX é composto pelas seguintes fases:
\begin{itemize}
   \item análise de requisitos;
   \item análise e projeto preliminar;
   \item projeto detalhado;
   \item desenvolvimento.
\end{itemize}

\subsection{Análise de requisitos}

\par A  análise de requisitos é um processo muito importante por definir os
recursos que serão empregados no projeto sobre as necessidades do cliente. Neste processo é definido 
o  escopo do  projeto,  uma  vez  tendo  os  requisitos  identificados  os  desenvolvedores  podem 
desenvolver as soluções. Mas para que tudo isso aconteça, o processo é subdividido em processos.
Na  primeira  fase  é  feita  uma  coleta  de  dados  abstraindo  todas as 
informações  que consistem no problema real, e assim define os objetos, as
ligações e suas  dependências, para  que  então  possa  ser  elaborada  a  documentação.  Após  a  documentação  ser  realizada,  a 
identificação dos objetos se torna visualmente clara para os envolvidos no projeto. O modelo 
utilizado nessa fase inicial é o modelo de domínio. Na Figura ~\ref{fig:modelo_dominio}, pode-se ver um exemplo de 
modelo de domínio.

\begin{figure}[h!]
   \centerline{\includegraphics[scale=1]{./imagens/modelo_de_dominio_rosenberg_EA.jpg}}
   \caption[Modelo de domínio]{Modelo de domínio. \textbf{Fonte:}
   \cite{rosenberg2005agile}}
   \label{fig:modelo_dominio}
  \end{figure}

%\subsubsection{Modelo de domínio}

\par O modelo de domínio pode ser visto como sendo a exemplificação dos objetos tendo como base relações 
do mundo real. Sua construção é realizada abstraindo as informações que foram descritas na análise de 
requisitos tendo como prioridade fornecer uma visão ampla das entidades, portanto não prioriza atributos e 
funcionalidades, ilustrando o relacionamento entre as entidades, definindo herança, dependências e agregações 
neste momento inicial quando os modelos são criados, mas podem sofrer
modificações de entidades que não foram levantadas em um primeiro
momento. Os autores reconhecem que inicialmente não se tem uma visão detalhada
do problema e a abstração dos requisitos será aprimorada ao decorrer do projeto.
Sendo assim este modelo sofrerá atualizações que serão acompanhadas nas fases futuras.

\par A criação do modelo de domínio, mesmo sendo inicial, deve ser feita o mais próximo possivel da visão final. 
Os criadores do ICONIX, \citeonline{rosenberg2005agile}, dizem que essa análise inicial deve
ser a mais clara possível e que todos os profissionais envolvidos no projeto e até mesmo futuros usuários devem entender 
de forma clara o modelo de domínio. Os autores ainda deixam claro que a importância em se criar um modelo de 
domínio mais perfeito possível tem ação direta na lógica de negócio, não tendo
como criação uma base de requisitos vaga, mas construindo seus modelos sobre requisitos sólidos.

\par Os autores também descrevem que, diante de um problema, são utilizadas técnicas para a criação de um 
modelo de domínio mesmo sendo destacado que a melhor construção sempre se dará através da  experiência do 
profissional a frente do projeto.

\par Como  visto  no  exemplo  anterior  o  modelo  de  domínio  é  formado  somente  pelos 
nomes  das  entidades  e  suas  ligações e após o  planejamento  do  modelo  de
domínio  ser encerrado, inicia-se a modelagem gráfica dos modelos, e suas
respectivas funcionalidades. As entidades  e  suas  interações  com  o  usuário 
são  exemplificadas  nesse  processo,  que  utiliza  o modelo de caso de uso, ilustadro, através de um exemplo, na Figura ~\ref{fig:modelo_uc}.

\begin{figure}[h!]
   \centerline{\includegraphics[scale=0.7]{./imagens/caso_de_uso_rosenberg_EA.jpg}}
   \caption[Exemplo de caso de uso]{Exemplo de caso de uso. \textbf{Fonte:}
   \cite{rosenberg2005agile}}
   \label{fig:modelo_uc}
  \end{figure}

\subsection{Análise e projeto preliminar}

\par Na segunda fase são feitos os primeiros diagramas e cada processo é definido como 
um  caso  de  uso.  Esse  modelo  exemplifica  toda  a  interação  do  usuário 
e  detalha  a  ação funcional de  cada entidade e suas dependências.  Segundo
\citeonline[p. 97]{rosenberg2005agile}, o planejamento de um projeto ágil ICONIX
é conduzido por caso de uso e fica extremamente difícil determinar o tempo de entrega de um projeto, sem antes determinar o que será entregue 
e é por isso que os casos de uso são utilizados para fornecer não apenas desenhos noções do 
que realmente será feito.

\par Mas para que haja um modelo que seja melhor interpretado,  a cada modelo de
caso de uso,  também  é  definido  um  modelo  de  robustez.  O  modelo  de 
robustez  define  regras  que exemplificam  melhor  a  análise  e  a  interação 
com o ator, que somente pode interagir com o sistema através de um objeto de
fronteira (\textit{boundary}). A fronteira pode ser exemplificada como uma
interface de usuário ou uma API.

\par Além  da  fronteira  (\textit{boundary}),  como  interação  do  usuário,  o 
diagrama  de  robustez utiliza-se de outros dois tipos de objetos, chamados
de controladores (\textit{control}) e entidade (\textit{entity}). 

\par Os  controladores representam as regras de negócio, a lógica do processo
e eles recebem diretamente a interação das fronteiras. Em sequência, os
controladores interagem com as entidades que são representadas como a forma que
as informações serão armazenadas. As entidades interagem somente com os
controladores. Na Figura ~\ref{fig:modelo_robuztez}, é mostrado um exemplo de diagrama de robustez.

\begin{figure}[h!]
   \centerline{\includegraphics[scale=1]{./imagens/diagrama_de_robustez_rosenberg_EA.jpg}}
   \caption[Exemplo de diagrama de robuztez]{Exemplo de diagrama de robuztez.
   \textbf{Fonte:}
   \cite{rosenberg2005agile}}
   \label{fig:modelo_robuztez}
  \end{figure}
\subsection{Projeto detalhado}

\par  Esta fase define mais detalhes descrevendo como a
aplicação irá funcionar. Neste ponto os métodos e funções que se encontram
presentes na documentação, ilustrando o
comportamento entre os objetos e as mensagens que são trocadas entre eles, associando métodos \textit{invokes}.

\par A elaboração dos diagramas de sequência é constituída de uma analise árdua, devido a ter sua ilustração 
no foco de detalhar o fluxo completo de uma tarefa na aplicação. Neste momento, \citeonline{rosenberg2005agile}
 recomendan que todos os diagramas de robustez já estejam finalizados, e
 definem que os diagramas de sequência devem mostrar como a aplicação irá
 iniciar e concluir uma tarefa. Este diagrama, ilustrado na Figura~\ref{fig:modelo_sequencia}, mostra a execução da tarefa baseada mas
 especificações dos modelos e diagramas anteriores e aproveita a base de eventos e sequência de cada diagrama.

\begin{figure}[h!]
   \centerline{\includegraphics[scale=1]{./imagens/imagem_sequencia.jpg}}
   \caption[Exemplo de diagrama de sequência]{Exemplo de diagrama de sequência.
   \textbf{Fonte:}
   \cite{rosenberg2005agile}}
   \label{fig:modelo_sequencia}
  \end{figure}

\subsection{Desenvolvimento}
\par Na quarta e última fase  é onde ocorre o desenvolvimento baseado em todas as 
análises feitas, os diagramas e modelagem dos objetos. Neste ponto, é feita uma reunião da 
equipe  para  verificar  se  todos  os  requisitos  estão  sendo  implementados  conforme  o 
planejamento feito na análise e modelagem dos diagramas.
\par Neste capítulo foram apresentados  as principais teorias que embasam esta pesquisa. No próximo capítulo serão abordados os procedimentos que tornaram os conceitos teóricos fundamentados, atravéz dos processos decorrente das necessidades durante a construção do projeto.  
 

